home *** CD-ROM | disk | FTP | other *** search
/ Network Support Library / RoseWare - Network Support Library.iso / pressgen / hsm.txt < prev    next >
Text File  |  1994-01-27  |  17KB  |  383 lines

  1.  
  2.  
  3. Introduction
  4.  
  5.  
  6.  
  7. Originally used to reduce storage and administration costs in mainframe and
  8. mid-sized systems, Hierarchical Storage Management (HSM) is now helping manage
  9. data on LANs. The theory behind HSM is the same for mainframes and LANs alike,
  10. primary on-line storage is costly if not managed efficiently. 
  11.  
  12. In LAN environments, the burden of storage management is heightened as it
  13. effects not only the network managers but nearly every user as well. Time spent
  14. dealing with the capacity of server and workstation volumes can add up to a
  15. loss far greater than the price of the disks themselves. By completely
  16. automating the management of disk capacity, HSM can deliver the benefits of
  17. near-infinite storage while minimizing cost, labor, and overhead.
  18.  
  19. This White Paper illustrates how HSM provides the best solution to the
  20. never-ending need to increase LAN storage. Refer to the glossary on the last
  21. page of this White Paper for a description of the terms used herein.
  22.  
  23.  
  24.  
  25. HSM: The first effective solution to the LAN storage dilemma
  26.  
  27.  
  28.  
  29. Disk volumes on LAN servers always fill up - it's almost a law of physics.
  30. Until recently, there have been only three ways to deal with the problem when
  31. it happens:
  32.  
  33.  
  34.  
  35. Approach #1
  36.  
  37. Buy more disk. This solution does solve the problem, but at a price. Disk
  38. storage on a server typically costs between $1,000 and $2,000 per gigabyte and
  39. twice that for mirroring, making continuing disk expansion rather expensive.
  40. But the disk drive is only the beginning, you also need controllers, cables,
  41. power, and physical space. Furthermore, as the on-line capacity grows, more RAM
  42. is needed for the file server to service disk cache, more disk connections are
  43. used in both software and hardware, and more and more backup systems are needed
  44. to protect the additional hard drive volumes of data.
  45.  
  46.  
  47.  
  48. Approach #2
  49.  
  50. Have the users remove "clutter." When buying more disks isn't a practical
  51. option, and the network manager doesn't have the time or appropriate tools to
  52. manage data, this is the only remaining option. While its apparent costs are
  53. zero (no disk or special software to purchase), this option is generally the
  54. least reliable and most expensive. Manual deletion of files is time consuming
  55. and inherently risky. Users may inadvertently delete files which are valuable,
  56. or they may remove so few files as to make the exercise pointless. It may take
  57. days for an administrator to convince users to clean up their act,' only to
  58. find they have also removed applications, important data files or application
  59. configuration files. While cooperation may have yielded some additional disk
  60. space, more time must be spent putting the system back in shape.
  61.  
  62.  
  63.  
  64. Approach #3
  65.  
  66. Migrate the files to off-line storage. This approach involves making extra
  67. off-line copies of inactive files, and then removing them from the on-line
  68. storage. This does allow space to be reclaimed in a reasonable time period, but
  69. has the drawback that user access to the migrated data is inconvenient at best.
  70. In most cases the users must request specific files from the system
  71. administrator and then wait for the data to be found in the off-line archives
  72. and then hopefully be restored. Often, users will not know the specific name or
  73. location of migrated data, and a more imprecise and often fruitless task of
  74. finding the data on off-line media must begin. This process may take hours or
  75. even days. And as the amount of migrated data grows, the recall requests can
  76. become unmanageable.
  77.  
  78.  
  79.  
  80. The HSM Alternative
  81.  
  82.  
  83.  
  84. HSM (Hierarchical Storage Management) is an automated process that provides
  85. the best solution to the never ending demand for increases in LAN storage. By
  86. moving inactive data to less expensive secondary storage, and recalling it
  87. automatically when needed, users receive the benefits of near-infinite disk 
  88. storage without the cost.
  89.  
  90.  
  91.  
  92. Figure 1. Storage Tiers
  93.  
  94.  
  95.  
  96. Compared to approach #1 (buying more disk), HSM provides the same 100%
  97. accessibility at a much lower cost. Compared to approach #3 (migrating old
  98. data), HSM provides the same cost savings without the administrative burden or
  99. inconvenience to the user. Compared to approach #2 (have users remove clutter),
  100. HSM allows users to go on doing productive work and handles the storage
  101. management tasks automatically and safely. Most HSM systems perform the three
  102. following basic functions:
  103.  
  104.  
  105.  
  106.    Pre-staging of inactive data to secondary storage. Some form of secondary
  107. storage is used. Typically, this takes the form of a tape autoloader, optical
  108. jukebox, a device such as a large tape drive or some combination of these
  109. devices. A key characteristic of the secondary storage is a cost per gigabyte
  110. much lower than that of magnetic disk (primary storage). The HSM system is
  111. responsible for moving copies of inactive files into the secondary storage, in
  112. anticipation of the need to remove them from primary storage as the disk
  113. volumes fill. (Data is pre-staged to avoid the performance burden of
  114. transferring large amounts of data during peak usage hours.)
  115.  
  116.  
  117.  
  118.    Monitoring of primary storage volumes with migration as needed. Throughout
  119. the day and night, the HSM system monitors the volumes it services. If the
  120. amount of data on the volume exceeds the configurable "high water mark"
  121. (usually expressed as a percentage of total disk space), migration will occur.
  122. If pre-staging has been used, this migration requires nothing more than
  123. selecting the right files to migrate, shortening them to a very small "phantom"
  124. or "stub" file as a place holder, and stopping the migration when the specified
  125. "low water mark" is reached.
  126.  
  127.  
  128.  
  129.    Automatic recall of files as needed. The users continue to see all data as
  130. on-line. When a file is accessed, a recall agent, resident in the client or in
  131. the server, initiates the process of moving the file from secondary storage
  132. back to primary storage.
  133.  
  134.  
  135.  
  136. These three processes combined allow for rapid LAN storage growth without the
  137. expense of on-line disk or the administrative overhead of manual storage
  138. management. As the disks fill, inactive files are moved off to less expensive
  139. storage, but remain accessible to users without administrator intervention.
  140.  
  141.  
  142.  
  143. Why is HSM for LANs such a visible topic now?
  144.  
  145.  
  146.  
  147. Several independent trends have converged to make HSM attractive for LANs.
  148.  
  149.  
  150.  
  151. Size of LAN storage
  152.  
  153. LAN data and storage continues to grow exponentially. Even with the decreasing
  154. costs of magnetic disks, keeping up with the storage growth is an expensive
  155. proposition. Beyond the costs of the disks themselves, issues with server
  156. configuration (RAM, SCSI ports, slots) and the time and cost involved in
  157. management of larger storage systems are creating a greater need for an HSM
  158. solution.
  159.  
  160.  
  161.  
  162. Figure 2. Typical LAN Capacity Profile
  163.  
  164.  
  165.  
  166. Availability of robotic storage devices
  167.  
  168. The last two years have seen an increase in availability and a decrease in cost
  169. of high-capacity autoloaders and jukeboxes. These robotic devices have matured
  170. in terms of both dependability and programmability, making them more reponsive
  171. to sophisticated software control. The ready availability of low-cost secondary
  172. storage is a prerequisite to HSM; the enhanced capabilities for these devices
  173. make them ideal storage management components.
  174.  
  175.  
  176.  
  177. Availability of HSM software
  178.  
  179. While file migration software (with manual restores) has been around for some
  180. time, truly automated HSM software has just recently been introduced to NetWare
  181. LANs in 1993. The automation of a true HSM system greatly improves usability of
  182. secondary storage. 
  183.  
  184. HSM is not a new concept. HSM systems, both automated and semi-automated, have
  185. served mainframe and minicomputer platforms for years. As LANs grow in
  186. complexity and storage requirements to the level of mainframe systems, the need
  187. for HSM becomes more apparent.
  188.  
  189.  
  190.  
  191. The Palindrome HSM Software Approach: Integrating Backup, Archiving, and HSM
  192.  
  193.  
  194.  
  195. Palindrome HSM Software operates in conjunction with Palindrome's award-winning
  196. Network Archivist backup and archiving software. Palindrome HSM Software builds
  197. on the intelligent storage management architecture of Network Archivist to
  198. provide a flexible, scalable HSM solution applicable to a wide range of LAN
  199. environments. In addition, the tight integration of Palindrome HSM Software
  200. with Network Archivist provides a total storage management environment, capable
  201. of managing the entire backup, archiving, and HSM functions in one seamless,
  202. robust, and easy-to-administer package. This integration provides superior
  203. reliability, it also allows surprisingly affordable implementation. Further,
  204. the modularity of the system approach also allows LAN sites to customize and
  205. configure their storage management environment to fit their individual needs
  206. and to grow as LAN size increases.
  207.  
  208.  
  209.  
  210. Figure 3. Palindrome HSM Software Architecture
  211.  
  212.  
  213.  
  214. Palindrome HSM Software is composed of Palindrome HSM Volume Monitor and
  215. Palindrome Client Recall Agents.
  216.  
  217.  
  218.  
  219. Palindrome HSM Volume Monitor
  220.  
  221. Residing as an NLM on NetWare servers, the Palindrome Volume Monitor checks the
  222. disk capacity of the servers under its protection at configurable intervals to
  223. determine how full the storage devices have become. When any disk exceeds its
  224. high-water mark - a level which the administrator has decided would be too full -
  225. the Palindrome system automatically converts data on the disk (which is
  226. eligible for migration and already pre-staged onto secondary media) to
  227. zero-byte phantom files. This migration of pre-staged data continues until the
  228. disk reaches its low water mark - a percentage of disk which is acceptably full
  229. and allows ample room for the server to continue running effectively. The
  230. monitoring capability of Palindrome HSM Software is extremely powerful and
  231. flexible. High and low water marks can be set individually for each server
  232. volume, permitting customized storage management according to a volume's
  233. capacity, storage requirements and disk activity. And prior to migration, files
  234. are permanently archived to ensure ability to restore.
  235.  
  236. The HSM migration process leaves behind zero-byte phantom files in the process
  237. of removing eligible files from storage - the file's original file name remains
  238. on the server, but the file itself has been removed. This phantom file is key
  239. to recalling the data at a later time. The order in which data is migration can
  240. also be customized in a number of ways:
  241.  
  242.  
  243.  
  244.    Least recently used. If the monitor is set for this option, the least
  245. recently used data is migrated first until the low water mark is reached. Files
  246. that have not been accessed the longest are less likely to be needed
  247. immediately and re good candidates for moving off primary storage. This option
  248. is easiest to understand, and to explain, and is the default option in
  249. Palindrome HSM. This option, however, may not be the best for all computing
  250. environments. 
  251.  
  252.  
  253.  
  254.    Largest first. If this option is chosen, all files that are eligible for
  255. migration are sorted by size and deleted from storage on that priority until
  256. the low water mark is reached. In any environment, regardless of applications
  257. used, this option always migrates the fewest possible files to attain its
  258. migration goals and therefore reduces any future restore requests. Fewer
  259. migrations and fewer restores result in increased system performance.
  260.  
  261.  
  262.  
  263.    Most Eligible. Depending on how an administrator sets the rules for
  264. migrating files, Palindrome HSM software can determine which files are most
  265. eligible to be migrated. For example, files that have a "quick" migrate date -
  266. say a few weeks - would be more eligible than files with 52-week migration
  267. eligibility dates. The system can be set to prioritize migrations in just such
  268. a manner. Those files which are "more eligible" are the first removed (i.e.
  269. their migration dates far exceed their migration rule).
  270.  
  271.  
  272.  
  273. Pre-staged Files and Eligible for Migration'
  274.  
  275. It's important to note that one of Palindrome HSM's strengths comes from its
  276. tight integration with the Network Archivist software. With file protection
  277. rules set in the backup and archiving software, files are redundantly protected
  278. across more than one piece of secondary storage, insuring that these files will
  279. remain protected even if one tape or optical disk is damaged, or a complete
  280. site disaster occurs. Once files are protected redundantly and reach the
  281. administrator's criteria for migration (not accessed for 12 weeks, for
  282. example), these eligible files can be simply converted to phantom files on the
  283. server as they've already been pre-staged to secondary media through the
  284. Network Archivist system of archiving. This instant' migration of eligible
  285. files from the server is an important advantage - no network traffic is
  286. generated moving files to secondary storage, and no separate migration
  287. operations need ever be performed.
  288.  
  289.  
  290.  
  291. Palindrome Client Recall Agents
  292.  
  293. Whether an attached workstation on the network is running DOS, Windows, or
  294. OS/2, the Palindrome Recall Agent is laded into the machine's memory at
  295. start-up. These agents run in the background waiting for the client's access of
  296. phantom files - zero-byte files left behind as place markers for migrated files
  297. (see figure 3, page 4). Users can access these files even within applications,
  298. calling up a migrated text file, for example, from within a word processor.
  299. When the filename is accessed, the recall agent steps in. First, the user is
  300. notified via a pop-up window that the file has been migrated and automatically
  301. queues it for restore. The recall agent submits the filename into the
  302. Palindrome queue where it is referenced in the Palindrome File History Database
  303. for immediate retrieval. 
  304.  
  305.  
  306.  
  307. User Notification and Control
  308.  
  309. No HSM system can be successful if it causes confusion or frustration for the
  310. users. When a file recall is in progress, a pop-up informs the user, showing
  311. the file name, queue status, and an activity indicator. The user has three
  312. options, to do nothing and let the recall complete, to continue without waiting
  313. (useful in recalling groups of files), or to delete the recall request. 
  314.  
  315. If installed, Palindrome's File Manager can allow users to initiate the recall
  316. of a whole project, rather than requesting the files sequentially via the
  317. recall agent.
  318.  
  319.  
  320.  
  321. Scalable HSM
  322.  
  323. Because Palindrome delivers an integrated approach to a storage management
  324. environment, implementing HSM on a LAN can be done gradually, as storage
  325. requirements demand and budget allows. A business can purchase Network
  326. Archivist for backup and archiving to tape, customize the Archivist rules over
  327. a period of time to get the optimal protection for their environment, and then
  328. move into HSM in their own way.
  329.  
  330. Many LANs can deploy basic HSM functionality with a single tape drive or pair
  331. of drives, for example. Due to Network Archivist's flexible media handling
  332. capabilities, one tape drive can be designated to handle incremental backup
  333. data while another tape drive is set to handle near-line storage. This larger
  334. tape can remain permanently in the drive to service demigration requests,
  335. adding 4-10 gigabytes of storage at low cost.
  336.  
  337. As LAN primary disk and migrated data demands grow, the administrator can add
  338. an optical disc, a tape autoloader, and optical jukebox or any combination -
  339. without re-implementation or lengthy configuration - to extend the reach and
  340. depth of the HSM services. 
  341.  
  342.  
  343.  
  344. Conclusion
  345.  
  346.  
  347.  
  348. Palindrome is the LAN industry leader in automated storage management. Plans
  349. and accommodations for the current HSM products were a part of Network
  350. Archivist's growth path since the shipment of Network Archivist in 1989. The
  351. thoughtful integration of HSM into the current product line is a natural
  352. evolution of the Palindrome storage management philosophy. The power,
  353. flexibility, and economy of the Palindrome HSM system make it the most
  354. responsive to the local area network environment, now and in the future.
  355.  
  356.  
  357.  
  358. Glossary
  359.  
  360.  
  361.  
  362. On-Line: hard disk drive (often referred to as primary storage).
  363.  
  364. Near-line: mechanically available data, usually stored on tapes or optical
  365. media; in an HSM system, end-users have no need to know whether a file resides
  366. on primary or near-line storage (often referred to as secondary storage).
  367.  
  368. Off-line: media held in a vault or on a shelf and not immediately available to
  369. the storage management software.
  370.  
  371. Pre-stage: to make copies of data eligible for migration onto secondary media.
  372. Once the data is protected redundantly, on multiple media, it can simply be
  373. removed from primary storage, as it has already been "moved" to secondary
  374. through pre-staging.
  375.  
  376. Migrate: to move data from one storage media to another, usually lower in the
  377. hierarchy.
  378.  
  379. Phantom file: a filename, occupying zero bytes, which stands as a placeholder
  380. for data which has been migrated from primary storage.
  381.  
  382. Recall: opposite of migrate; bring back to primary storage.
  383.